This fixes #370.

In prod mode, it registers the cyd:// protocol, and in all other modes it registers the cyd-dev:// protocol. In case it helps with review, here's a docs that explain how this is supposed to work. Note that there's differences between how macOS works and how Windows/Linux works.

While this may change, right now the hostname needs to be social.cyd.api or social.cyd.dev-api. Here are how various URLs should behave:

• cyd-dev://asdf/ <-- should open/focus Cyd Dev and pop up a dialog saying the hostname is invalid
• cyd-dev://social.cyd.dev-api/ <-- should open/focus Cyd Dev, and that's it
• cyd-dev//social.cyd.dev-api/anything-else-here <-- should open/focus Cyd Dev and pop up a dialog saying it's an invalid path

When testing in each platform, you need to actually build the installer and then install it, and then test on that final installed version. We need to test these URLs in these two cases:

• Cyd Dev is closed. It should open it and then handle the URL.
• Cyd Dev is already open. It should focus the window and then handle the URL.

I think this should work in all cases except for Windows, when Cyd Dev is closed. For some reason it's not opening in that case, and I can't quite figure out why. So while you're reviewing this PR, any ideas would be appreciated (or if you aren't reproducing the problem I think I'm seeing that would be cool too).

This PR also changes how logging works. Before it never logged to file and only to the console. Now, in prod mode it only logs to the console, but in all other modes it logs to disk. You can find the logs here:

• macOS: ~/Library/Logs/Cyd Dev/main.log
• Linux: ~/.config/Cyd Dev/logs/main.log
• Windows: %USERPROFILE%\AppData\Roaming\Cyd Dev\logs\main.log

By tailing these files, you can tell when a new Cyd process launches and also you should be able to see the URLs that get passed in.

The way I've implemented it, if the app has not been initialized yet, it adds Cyd URLs to a queue instead of just processing them. Once the app is initialized, it processes everything in the queue. This is required to make Cyd URLs pop up dialog boxes, because that requires the app to be initialized.

Testing in macOS

Make a build:

npm run make-dev-macos

Eventually you'll get to a "Preparing to notarize macOS artifacts" step and you can press Ctrl-C to quit it early. Then, there will be a DMG in out/make/. Open it and drag "Cyd Dev" to Applications, and open it once -- this should register itself as a cyd-dev handler.

To test URLs:

open cyd-dev://asdf/

Test with both Cyd Dev closed and open.

Testing in Linux

Make a build (check this Dockerfile for what linux deps you need installed -- I've had an easier time building both RPM and DEB from Debian rather than from Fedora):

npm run make-dev-linux

This will make a DEB in out/make/deb/ and an RPM in out/make/rpm/.

Install the DEB and/or the RPM. I've only tested .deb myself so far, but .rpm should be the same, though it might not. One reason it's important to test the DEB and RPM separately is the build process makes their .desktop files, and this file needs to be properly created to handle new protocols.

To test URLs:

xdg-open cyd-dev://asdf/

After installing, test with both Cyd Dev closed and open.

Testing in Windows

Make a build:

npm run make-dev-windows

This will create an EXE installer in out/make/squirrel.windows/{arch}/. Double click it to install.

To test URL, press Windows-R, type the URL like cyd-dev://asdf/, and press enter.

After installing, test with both Cyd Dev closed and open.

In my testing, if I'm tailing the logs (which I do in Git Bash since PowerShell doesn't have tail, and my Windows VM doesn't have WSL) and Cyd Dev is already open in Windows, it success in processing the cyd-dev:// URL. But if I completely close Cyd Dev and then try it, it just doesn't seem to do anything -- I can tell that it's not launching a new Cyd process because the logs don't print anything. I don't know why, so this needs to be fixed before it's ready to merge.